Largest restorable archives

Chris_Welch - Mon Dec 28 08:50:36 EST 2009
Did you check the server's TEMP folder location to see if it had enough disk space?

Dartguru - Tue Jan 05 04:16:48 EST 2010
Okay, I might need some help understanding this ...

I have the archived project on a PC and am restoring it to a database on a CITRIX server.

I think we've ascertained that the CITRIX server has enough space, although I am getting confirmation for the server's TEMP folder space.

Why would I need any space on MY temp folder - and how can I find out where it would be ?

SystemAdmin - Tue Jan 05 09:50:05 EST 2010
I believe that the previous replies are trying to convey that the Restore\Archive process uses local pc \temp folder space during processing of either the Restore or Archive action as well as \temp folder space on the destination server when you decide to restore to your Citrix server.

I can add that when creating the Archive file, the existing DOORS project server also requires enought extra space available that matches the Archive file size in order to do the server side processing. ie. it creates a large zip file which ends up being left behind as residue in the \doors\data folder if-when it completes your Archive file where ever you decided to save it.
Then when you kick-off the Restore of that Archive file to go to your Citrix server DOORS database, that is when the Citrix server \temp folder is going to come into play, as well as your local pc \temp folder again.

The Archive\Restore process can take a long time on 10 Megagit networks since it passes all the info back and forth from server to local pc "twice" and then performs some sort of top to bottom integrity check close to the end of the Archive\Restore Process.

Keep in mind, you will not get your Users, Groups, and Links to other projects when you move DOORS projects from one database to another database. Can be a big DOORS Admin project to get it setup again if you are expecting the same users to dive into the new location after a Restore action.

Good Luck...

SystemAdmin - Tue Jan 05 09:50:05 EST 2010
I believe that the previous replies are trying to convey that the Restore\Archive process uses local pc \temp folder space during processing of either the Restore or Archive action as well as \temp folder space on the destination server when you decide to restore to your Citrix server.

I can add that when creating the Archive file, the existing DOORS project server also requires enought extra space available that matches the Archive file size in order to do the server side processing. ie. it creates a large zip file which ends up being left behind as residue in the \doors\data folder if-when it completes your Archive file where ever you decided to save it.
Then when you kick-off the Restore of that Archive file to go to your Citrix server DOORS database, that is when the Citrix server \temp folder is going to come into play, as well as your local pc \temp folder again.

The Archive\Restore process can take a long time on 10 Megagit networks since it passes all the info back and forth from server to local pc "twice" and then performs some sort of top to bottom integrity check close to the end of the Archive\Restore Process.

Keep in mind, you will not get your Users, Groups, and Links to other projects when you move DOORS projects from one database to another database. Can be a big DOORS Admin project to get it setup again if you are expecting the same users to dive into the new location after a Restore action.

Good Luck...

Dartguru - Tue Jan 05 10:02:52 EST 2010
Thanks for the reply.

I've had a look for a temp folder on my PC. There is indeed one on my C: drive (a 25GB drive with 9.6GB free). Would I expect to see some residual files left (I don't)?

Regarding restoration of a 10GB project, you imply you've done it and it worked (correct me if I'm wrong), which is very helpful to know.

Regarding the users and groups when moving from one DB to another, we have a script supplied by Telelogic (yes the move started that long ago), which stores the project configuration and enables use to restore it at the other end.
It SEEMED to work okay when trialled 18 months ago.

SystemAdmin - Tue Jan 05 11:15:35 EST 2010
Yes, this actually was done as recent as December 2009.
I had to resurrect a DOORS v 8.1 database project that went out of service in April 2009.
We restored from IT backup system tapes "the entire DOORS v 8.1 database" onto a special server from just prior to the out of service date.
The DOORS v 8.1 Project Archive file then created was a 5.3 Gigabyte size when done.
Of course that created the need for a dual layer dvd, fun never ends with this stuff.
We sent this to our customer, not sure what the fully restored from DOORS archive Project size is, but like yours it probably exceeds 10 Gig. Our entire DOORS v8.1 database exceeded 50 gig before we updated to DOORS v9.1. and has approx. 25 projects on it.
It is not practical for me to spend the time building a server with just this single project on it to find out what the actual restored from archive size is, however I am certain it is over 10 gig.

NOTE: The archive residue gets left behind on the source DOORS v8.x server, usually as a zip file left behind under the \doors\data folder in the DOORS v 8.x environment, this residue is NOT in the \temp folder.
The \temp folder can sometimes contain some LD_08ax5c3 type folders that are some sort of cache that DOORS clients use. over time you can clean those up if you need to. dont delete them if you are running the DOORS client, as it is where unsave work is until you save and log out of DOORS on the client pc.
I used to periodically go look for residue server since any DOORS user with Database Manager level or custom setting can creat archives, which then residue was taking up valuable space on our production server.

SystemAdmin - Tue Jan 05 11:29:14 EST 2010
my final word of advice...
You will need to exercise alot of patientce on this very large restore, I estimate it will take at least 4 hrs. when restoring from a pc onto a server over the network.
estimate based upon my archive creation took that long, and the restore typically takes just as long.

Dartguru - Wed Jan 06 02:59:54 EST 2010
Thanks.

I think you've confirmed my understanding that the issue is with disk space (somewhere, yet to be identified), and not a problem with restoring such a large project - which is a relief.
I can quite well believe that this will take "at least" four hours, as it's taken longer than that to fail in previous attempts.

SystemAdmin - Wed Jan 06 14:06:07 EST 2010
Curiosity about your Citrix server comments above....
Are you really running a DOORS database ON the Citrix server????
Or are you just running a Citrix server with a DOORS client to access the DOORS database located on another server?
REASON: if you are indeed running the DOORS database right on the Citrix server, AND if it also has the DOORS client already installed....you can speed up the project.dpa restore activity by placing the .dpa file onto the Citrix server, start the DOORS client, run the restore project.dpa, and it will process much faster since it is all located on the Citrix server and not passing out thru slow nic and ethernet and a remote pc.

BIGGEST CONCERN: if you do not already have the DOORS client installed on the Citrix server where the DOORS 8.x database is installed and running, and you decide to install the DOORS 8.x client, it will require a server reboot, not sure you can tolerate that or not.
Normally, if you check the install manuals it will confirm this order of events, typcially, you are to install the client BEFORE the server if you wish to run the client on the DOORS server, that is, if you don't want to have to reboot the DOORS 8.x server.... i hope you can follow this. Some folks choose not to install the client onto the server and keeps server cleaner, but it can hamper issues like this later.